pp108 : Setting Properties of an Application Package

Setting Properties of an Application Package

This topic describes the procedure to set properties of an Application Package.

The properties of an Application Package will determine how you want to package the application content. You may either package application content to be run as an application or package it so that it is open for minor modifications at runtime and then publish it for actual use. Depending upon the settings, the output file (Application Package) will differ.

  1. In Workspace Documents, right-click <project> and select Packaging > Package Properties. The Application Package Properties window appears, displaying fields across two tabs.
  2. Enter the following information on the General tab.

    Field/Option

    Description

    Package for

    There are two options: 
    • Runtime - If the Runtime option is selected, the application package can only be deployed and used as is. 
    • Staging - If the Staging option is seleceted, the resulting application package will be loaded into the Staging Area. This allows you to align certain application artifacts to production environment specific configurations before publishing the application to the run time. In addition, this als enables business operations managers to update business-critical application parameters instantly, that is without requiring engineering activities.

    Caution: A package created for staging cannot be upgraded to later versions. Also, if such a package is unloaded, the changes that were made to it will be removed from all the organizations. Therefore, consider these points before choosing to create a staging application package.

    Package Owner

    Owner of the Application Package.

    Product Name

    Name of the product or application that is packaged.

    Version

    Version of the application. The version can be alphanumeric.
    Note that while upgrading an ISVP, a comparison of ASCII alphanumeric values is performed. The comparison is not case-sensitive.
    Upgrade is possible only when the new version has a higher ASCII value compared to the old version. For example, upgrade is possible from version 1.0 to 2.0; while is it not possible to upgrade from the versions 9.0 to 10.0 and abc23.5 to ABC2.87.
    Note: Version is a free string. The following characters * ~ ` @ # % ^ & ( ) { } [ ] | \ / ? , > < + = " ' : ; are not allowed while naming the version for the package. for example: Version can be A1.001.002 or B1.001 or C.002.004 and so on. Also, ensure that while specifying the version for the current package, it is always greater than the older version of the same package; this enables the current package to be considered for upgrade.

    Build Number

    A unique number representing the build of the application that is packaged. This number helps you to keep a track of successive builds of the application package and is useful while upgrading an Application Package from one build to another. The number given here should always be greater than the one given for the previously created Application Package. Build number allows numerals between 0 and 9 and can be delimited by a dot(.). For example: 123.457.
    Note: Build is a concatenation of two integers, separated by a dot; the second integer is optional. For example, the build number can be 500.12345 or 204.56795 or just 2356. Also, ensure that while specifying the build number for the current package, it is always greater than the older build number of the same package; this enables the current package to be considered for upgrade.

    Supported Deployment Spaces

    Spaces in which the package is allowed to be deployed. You can deploy packages either in the shared space or in organization spaces. If you select only the 'Shared' space, then this package can only be deployed in the shared space, making the functionality available for all organizations. Similarly, if you select only the 'Organization' space, then this package can only be deployed in organization spaces. If you select both the levels, then this package can be deployed in both the shared spaces and in organization spaces. For more information, refer to Managing Application Packages in the Organization Space.

    Note: You must select at least one of the supported deployment spaces. However, you can deploy the staging packages only in the shared space. As such, it is not possible to select the 'Organization' space when the property 'Package for' is set to 'Staging'.

    Package Name

    Name of the Application Package. It determines the uniqueness of the application and the value is checked during an upgrade. By default, this will display the values entered in Package Owner and Product. This will be the name by which the Application Package will be stored in LDAP.
    Caution: Modifying the Package Name may interfere with the upgrade process of the previously installed application package.

    Package File Name

    A file name given to the Application Package. If you are creating the Application Package for use at run time, the file extension will appear as .cap. If you are creating the application package for modifications at run time, the file extension will appear as .staging.cap. By default, this will display the information as in the Package Owner and Product Name appended by the Version and Build Number, in that sequence.
    Note: This name cannot contain any special characters.

    Package Description

    Description of the Application Package

  3. Click the License Agreements tab to enter the license agreement information. This is a place where you can specify an End User License Agreement (EULA) along with the application content, if required. The license content will be displayed for acceptance while loading the Application Package. The EULA could either be in .txt or .html format and must be uploaded to the project you are packaging.
  4. Click next to the End User Legal Agreement field. The Package Info dialog box appears, displaying all the TEXT and HTML files available in the Workspace. The selected EULA will appear in the output field as a hyperlink. Clicking the hyperlink will open the linked file. To remove the EULA, you can click .
  5. From the list of file names, select the license agreement file that is available, and click OK. The Package Info dialog box closes and the file name of the license agreement along with the project name appears in the End User Legal Agreement field.
  6. Add license information of any third party JAR used in the project, in the following manner:
    1. Click . A row is added to the table.
    2. Under the JAR column, click to browse and select the JAR available in the project. The names of the JAR and the project which contains it appear next to .
    3. Under the JAR Description column, provide a description for the selected JAR file.
    4. Under the JAR Legal Text column, click to browse and select the license agreement file that is available in the project. The names of the license agreement file and the project which contains it appear next to .
    5. Under the JAR Legal Text Description column, provide a description for the selected JAR license agreement.
  7. Click OK.
    The properties for the Application Package are set.

    Note:
    You can modify these properties at any time on both General and License Agreements tabs, and click OK to save the changes.

Related tasks

Modifying the Contents of an Installed Application Package
Publishing a Modified Application to Run Time

Related information

Managing an Application Package